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Abstract — Sequence diagrams are a widely used design notation for 
describing software behaviors. Many reusable software artifacts such 
as design patterns and design aspects make use of sequence diagrams 
to describe interaction behaviors. When a pattern or an aspect is reused 
in an application, it is important to ensure that the sequence diagrams 
for the application conform to the corresponding sequence diagrams 
for the pattern or aspect. Reasoning about conformance relationship 
between sequence diagrams has not been addressed adequately in 
literature. In this paper, we focus on required behavior specified by a 
UML sequence diagram. A novel trace semantics is given that captures 
precisely required behavior specified by a sequence diagram and a con- 
formance relation between sequence diagrams is formalized based on 
the semantics. Properties of the trace semantics and the conformance 
relation are studied. 

Index Terms — required behavior; refinement; conformance; semantics; 
sequence diagrams; 



1 Introduction 

The Unified Modelling Language (UML) sequence di- 
agrams 1 63 1 and their predecessors Message sequence 
charts Il68ll are specification languages that have been 
widely used for specifying interaction behaviors in soft- 
ware development. A sequence diagram (SD) describes 
inter-object/inter-process behavior of a system in graph- 
ical manner. It shows as parallel vertical lines differ- 
ent objects or processes that communicate with each 
other via messages that are shown as horizontal arrows. 
Each message has an associated sending event and an 
associated receiving event. Events are basic behavioral 
constructs of UML SDs. They can be combined to form 
larger behavioral constructs called fragments. A frag- 
ment is either an event or formed of an interaction 
operator, one or two operands which may be themselves 
fragments and an optional condition. It involves a col- 
lection of lifelines and is formed of events and smaller 
fragments. In this paper, we shall use the terms SD and 
fragment interchangeably 

Example 1.1: We shall use SDs in Fig.[I]as a running 
example. In SD Login, the alt fragment is labelled a 
and the sending and receiving events for a message are 
labelled with two consecutive numbers. Let e; abbreviate 
the event labelled i. For instance, e\ abbreviates lid the 
sending event of message id and e 2 abbreviates lid 
the receiving event of message id omitting the sender 



and the receiver of the message. The SD Login may be 
thought of as a pattern for a user to sign in to get a 
service from a server. The user provides to the server 
his user-id id and password pwd. The server checks if the 
user-id and password are correct using a system variable 
OK to indicate the result. If OK equals true then the user 
issues a command cmd to the server. 

1 .1 Motivation 

Software development can greatly benefit from reusing 
existing artifacts including architectural patterns, design 
patterns, design aspects, software components and code. 
An important issue that arises in reusing an artifact is 
how to ensure that the desirable properties of the artifact 
are preserved. This issue becomes harder and more 
critical when the artifact involves significant interaction 
behaviors. Many reusable artifacts make use of SDs to 
specify interaction behaviors. If an artifact is reused in 
an application, it is important to verify that the SDs in 
the application conforms to the SDs in the artifact. Other- 
wise, the intended benefits of the artifact cannot be guar- 
anteed. A special case of reuse is refinement in which 
an SD developed in an earlier stage is refined to obtain 
an SD in a later stage. Software design is an iterative 
process. Starting with an initial design model, a series 
of design models are obtained, each of which refines its 
predecessor. This process is applied to behavioral models 
as well as structural models. Each immediate model 
needs be verified against its predecessor. A fundamental 
issue arising from using SDs is whether one SD model 
correctly refines its predecessor in that it possesses all 
required behaviors that are mandated by the predecessor 
and at the same time rejects all proscribed behaviors that 
are prohibited by its predecessor. 

Example 1.2: Consider SD Login again. Let t = 
e\eie3,e/±e§e§ and t' = exe^e-ie^e^es. Let n = t[OK = 
truele^es, r 2 = t[OK = false], r[ = t'[OK = true]ere%, 
r' 2 = t'[OK = false], SD Login specifies two alternative 
minimum obligations O = {ri,r 2 } and O' = {ri,r 2 }. 
A system satisfies SD Login if it fulfils one of the two 
obligations. A system fulfills O if it has runs that produce 
the trace r\ and runs that produce the trace r 2 . A system 
that fulfils O' can be described similarly That guard 
conditions occur in traces shall be explained later. 
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Fig. 1. Sequence Diagrams for the Running Example 
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In aspect-oriented software development, design mod- 
els may be developed by composing aspects with pri- 
mary models, which involves composing sequence and 
class diagrams from aspects l24l . It is necessary to verify 
that the composed SD conforms to each of the compo- 
nent SDs. In pattern based development, the designer 
needs to check if an SD developed by the designer 
conforms to the behavior of a design pattern (25ll in 
the sense that it is a valid realization of the pattern. 
The purpose of using design patterns is to improve 
the quality of software designs. However, an invalid 
realization could break the design rather than improve 
its quality. Various efforts have been made to facilitate 
pattern realization. A common approach is using tem- 
plates where pattern participants are parameterized (e.g., 
see l28l , IHHI ). A pattern is instantiated by stamping 
out the template with parameters bound to application 
elements. In many cases, instantiated pattern realizations 
often require significant modifications such as adding 
new elements or modifying instantiated elements to 
accommodate application-specific needs. Since these ac- 
tivities may break pattern conformance and compromise 
the benefits of using design patterns, it is imperative to 
check if the application conforms to the pattern. 

An SD is partial in that it describes a number of alter- 
native obligations that an implementation may choose to 
fulfil. For instance, the fragment operator par does not 
mandate that an implementation must be distributed, 
concurrent or multi-threaded. It rather indicates that 
the implementation can realize any interleaving of the 
behaviors of its operands. When the SD is reused, it is 
made more defined in that the number of alternatives 
is reduced. An SD under reuse may be undergone a 
numbers of changes including the following. Firstly the 
names of lifelines and messages may be changed. Such 
changes are necessary to avoid names conflicts or to 
better reflect the developer's intention. For instance, the 
lifeline user in the SD Login may be renamed to customer 



for a business application. Secondly, control structure of 
the SD may be changed to eliminate non-determinism. 
Finally, new messages (and hence new events) may be 
added. 

Example 1.3: The SD Login2 describes a sign-in 
interaction for a customer of a brokerage and can be 
obtained by refining SD Login as follows. Firstly, the 
developer renames user to customer, server to brokerage, 
id to acc, pwd to pin, chk to chkP, OK to pOK and cmd to 
trade. The developer then eliminates non-determinism by 
requiring that lace occurs before Ipin. He also introduces 
a new system variable kOK and two new messages key 
and chkK which produces output kOK. The condition for 
the opt fragment has also been strengthened. 

That SD Login2 conforms to SD Login can be infor- 
mally checked as follows. SD Login3 may be obtained 
from SD Login2 by hiding messages key and chkK, using 
default value true for kOK and changing the names back. 
Moreover, SD Login3 is same as SD Login except that in 
SD Login3, ?id must occur before !pwd while they can 
occur in any order in SD Login. Formally, SD Login3 
specifies one obligation which is O given in Example ll.2l 
Any system satisfying SD Login3 fulfils O - one of 
the two alternative obligations of SD Login. SD Login2 
conforms to SD Login because SD Login3 is obtained 
from SD Login2 by renaming and hiding and it specifies 
O. 

The above example illustrates conformance checking. 
In conformance checking, an SD is verified to conform 
to another with respect to a set of unobservable events 
U and a mapping p that changes the names of system 
variables, lifelines and messages and assigns default 
values to some system variables. Conformance inference 
on the other hand infers automatically possible U and 
p with respect to which an SD conforms to another. 
Conformance inference requires a formalization of a con- 
formance relation between SDs which in turn requires a 
formal trace semantics that captures precisely behavior 
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of SDs. 

1.2 Contributions 

In the existing trace semantics ITTT1 , [34], [62[, an SD 
denotes a set of all possible traces that the specified 
system may produce and a set of proscribed traces 
that the specified system must not produce. They are 
useful as a semantic base for verifying SDs against safety 
properties. However, they are not useful as a semantic 
base for a conformance relation between SDs since they 
do not tell which possible traces are required in that 
the specified system must produce. As a special case of 
conformance, refinement has been studied for statecharts 
and modal transition systems. However, translations 
from SDs to these state machine models either have 
not been proved correct with respect to a formal trace 
semantics or introduce behaviors that are not required by 
SDs. Thus, results on refinement of these state machine 
models do not carry over to SDs. Related work will be 
discussed in Section |2 

In this paper, we give a trace semantics that character- 
izes required behavior specified in an SD and formalize 
a conformance relationship between SDs. Conformance 
is defined in terms of a simulation relation between 
traces. The notion of one trace simulates another will be 
made clear later. Roughly speaking, a trace t\ simulates 
another trace t 2 if all events in t 2 are simulated in t\ in 
order in which they occur and there are no observable 
events in t\ other than those that simulate events in t 2 . 
An SD D\ refines another D 2 if an implementation of 
D\ is also an implementation of D 2 . In other words, D\ 
preserves required behavior of D 2 but may specify more 
required behaviors. An SD Do conforms to another D 2 if 
there is an SD D\ such that D\ refines D 2 and D\ can be 
obtained from Do by renaming lifelines and messages, 
hiding events and assigning values to system variables. 
These concepts will be made clearer in Section [5] 
The main contributions of this work are as follows. 
• A novel trace semantics is formulated for a subset 
of UML SDs. Unlike the trace semantics proposed 
in literature [11], [34], [62 J that capture possible be- 
havior of SDs, our trace semantics captures precisely 
required behavior of SDs and forms a basis for a 
semantics based conformance relation. As discussed 
in Section |2 a conformance relation should not be 
based on a semantics for possible behavior of SDs. 
While those trace semantics for possible behavior 
of SDs ignore guard conditions, our trace seman- 
tics encodes guard conditions in SDs as elements 
of traces. This is required to ensure soundness of 
conformance, as discussed in Section [2] The seman- 
tics possesses substitutivity which is not enjoyed 
by trace semantics proposed in literature [11J, [34 1, 
[62|. A nice consequence of substitutivity is that a 
component of an SD can be replaced with a seman- 
tically equivalent component without changing the 
semantics of the SD. 



> A conformance relation between SDs is defined 
based on the semantics. A desirable property of 
the conformance relation is that it allows messages 
and lifelines to be renamed during conformance. 
The conformance relation is transitive, implying that 
conformance can be verified in step wise manner. 
The rest of the paper is organized as follows. Section [2] 
discusses about related work. Section [3] presents an 
abstract syntax for SDs and Section |4] defines the trace se- 
mantics. Section [5] defines the conformance relation and 
Sections [6] and [7] present two case examples. Section [8] 
concludes. Proofs are placed in an appendix. This paper 
is an extension of l45l . The conformance relation pre- 
sented in this paper generalizes the refinement relation 
in l45l by taking into account event hiding, renaming of 
lifelines and messages and assignment of values to sys- 
tem variables. The extension includes the conformance 
relation in Section 5.3, two case examples in Sections 6 
and 7, and proofs in the appendix. Section 2 is written to 
include more detailed discussion of related work. Other 
sections are written to include more examples and to 
improve presentation. 

2 Related Work 

We shall now put our work in the context of the exist- 
ing work. Since our work is concerned with semantic- 
based conformance reasoning for SDs, we focus on 
observational semantics of and conformance /refinement 
relations on SDs and their variants. For a survey on 
semantics of SDs, see I15T1 . 

2.1 Syntactic-based Refinement and Conformance 

Mauw and Reniers propose instance refinement for In- 
terworkings Il50l . Interworkings are similar to MSCs 
except that messages in Interworkings are synchronous 
and have only two interaction operators: seq and par. 
When an instance is refined, it is decomposed into 
several component instances and new messages may be 
added between these component instances. Engels IITHl 
studies message refinement for basic MSCs (bMSCs) 
which are MSCs without interaction operators. A mes- 
sage m in a bMSC k is refined by another bMSC p which 
has two distinct instances s and r corresponding to the 
sender and the receiver of m respectively. The refined 
bMSC, denoted k[p/m], is obtained by removing m and 
splicing p into k such that orders on events imposed 
by k and p are preserved. In addition, any event in k 
preceding \m now precedes all sending events on s and 
any receiving event on r now precedes all those events 
that follow ?m in k. Muscholl et al. (53), (54] call a bMSC 
M to match another N with respect to a set of messages 
T if M can be obtained from N by removing zero or 
more messages in T. The matching relation is extended 
to hierarchical MSCs (HMSCs) which are automata with 
bMSCs as transitions. An HMSC H matches another K 
if there is a pair (pi,p 2 ) of paths of H and K such that 
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bi matches b 2 where 6, is sequential composition of all 
bMSCs along pi for i = 1,2. Khendek et. al |38| propose a 
notion of conformance for MSCs. A bMSC M2 conforms 
to another bMSC M\ if A/2 can be obtained from Mi 
by refining one or more instances in Mi and adding 
new messages between new and/or existing instances. 
The conformance relation is extended to HMSCs that are 
sequential compositions of bMSCs. The HMSC seq^jMi 
conforms to seqj^jNj if there is an Mj conforming to 
Nj for each j e J. The above notions of refinement, 
matching and conformance are syntactic-based in that 
they are decomposing, introducing and removing in- 
stances and messages. They are defined for a subset of 
both MSCs and SDs. While they represent some reuses 
of MSCs, they are restrictive. For instance, they do not 
always allow us to replace one MSC with a semantically 
equivalent MSC. Thus, a notion of conformance based 
on semantics is needed to allow more flexible reuse. 

2.2 Direct Style Semantics and Refinement 

There is little work on semantic -based conformance in 
general. However, semantic-based refinement which is a 
special case of semantic-based conformance has attracted 
much attention. In llOl , |TT) and l62l , the semantics of an 
SD is a pair consisting of a set of positive traces and a set 
of negative traces. Haugen et al. [34[ define the semantics 
of an SD as a set of obligations all of which must be 
fulfilled. Each obligation is a pair consisting of a set of 
positive traces and a set of negative traces. Without the 
fragment operator xalt which they introduce to capture 
the required non-determinism, the semantics of an SD 
contains a single obligation and is equivalent to that of 
(62). Lund and Stolen provide an operational semantics 
for UML SDs l47l which is sound and complete with 
respect to the trace semantics of [34]. There is no dis- 
cussion on refinement in [47|. Refinement in (TT), [34], 
l62l is defined as eliminating positive traces and making 
them proscribed. Under this interpretation, the system 
is only required to have one of positive traces, which is 
problematic as shown below. For SD Login, the set of 
positive traces is {teres, t'e^es, t, t'} where t and t' are 
given in Example 11.21 The set of positive traces does 
not capture precisely required behavior of SD Login. As 
shown in Example 11.21 the specified system does not 
need to produce all positive traces in order to satisfy 
SD Login. It only has to produce t and te^eg, or t' and 
t'e 7 e$. 

A logical semantics for basic SDs is presented in (14). 
A basic SD D has only finite number of finite traces. The 
semantics of D is a temporal logic formulae with freeze 
quantifier fl3l . The semantics captures a single set of 
possible traces and applies to a small subset of SDs. SDs 
are formalized in [3] as PVS theories that specify a set of 
possible traces for each object in the system. Refinement 
is not discussed in |3), [14 1 . 

The above trace semantics 0, HU, QD, |34), E2 
associate an SD with a set of possible traces. They are 



useful for verification of SDs against safety properties 
of SDs such as dead-lock freedom [2|. However, they 
are inadequate for SD conformance reasoning in several 
aspects. Firstly, they do not distinguish required behav- 
iors from optional behaviors as pointed out in [59 1. Sec- 
ondly, they ignore guard conditions, which compromises 
soundness of conformance reasoning. For instance, let 
D\ = alt(c, \m, In) and D 2 =\m then ignoring constraints 
would assign two traces !m and !n to D\ and one trace 
!m to D 2 and lead to a false conclusion that D\ possesses 
all required behaviors of D 2 . In fact, D 2 requires the 
specified system to produce !m in all runs whilst D\ only 
requires the specified system to produce !m in those runs 
that starts with system states in which the condition c 
holds. Thirdly, they do not deal with critical regions ad- 
equately. All but one [62] of above mentioned semantics 
are defined for SDs with critical regions. Semantics in 
l62l does not possess substitutivity in the presence of 
critical regions. Let D\ be critical(strict(!a,!b)) and D 2 
strict(!a,!b). Then D\ and D 2 have the same meaning 
according to Il62l but par(L>i,!c) and par(Z? 2 /!c) do not. 

The semantics in (44| captures the effect of a syn- 
chronous message specified by an SD on logical proper- 
ties of the specified system. It abstracts away too much 
details of interactions and hence is not amiable to analy- 
sis of trace properties including behavioral conformance. 
The same applies to logical semantics for MSCs in (7). 

2.3 Translation to Automata and Process Calculi 

SDs and their predecessor MSCs have been studied via 
translation to automata, process calculi and other for- 
malisms. Mauw and Reniers l49l present a process-based 
semantics for basic MSCs (in short bMSCs) which are 
MSCs without fragment operators. A bMSC is translated 
to a process in ACP [5j. Chen et al. provide semantics 
for bMSCs with data [12) by translating a bMSC to a 
process in a variant of CCS (52). 

Whittle and Schumann generate statecharts from a 
collection of UML SDs and a collection of OCL con- 
straints [69]. Ziadi et al. translate a scenario specification 
in UML SDs into statecharts (71). As noted in (71), such 
translations result in statecharts whose behaviors include 
all behaviors of the scenario but include behaviors that 
are not required by the scenarios. Hammal defines the 
semantics of an SD as an automaton whose states are 
maps from objects to traces and whose edges are labelled 
with events l29l . To obtain a finite automaton, possible 
traces that contain the same set of events are identified. 
An SD has also been translated to a Petri net (e.g., [8], 
C3/ ED) with lifelines translated to processes, actions to 
transitions and messages to communication places and 
to abstract state machines (e.g., (9), 141) , l70l ). Refine- 
ment is not considered in (8), (9), IE), |20), |29), E), 

ED, ED, CD. 

Grosu and Smolka give safety and liveness semantics 
for SDs in terms of Biichi automata |27). Refinement is 
defined as set containment. Knapp et al. [40] translate 
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SDs to automata for model checking using the SPIN 
model checker. Alur et al. translate MSCs to automata 
for checking against safety properties such as dead-lock 
freedom (TJ, (J). Refinement is not discussed in (T), Q, 

ma. 

Uchitel et al. l66l synthesize a labelled transition 
system (LTS) from MSC scenarios and use it to detect 
scenarios that are implied by positive and negative 
scenarios (67). An LTS is a finite state machine with 
each transition labelled with an action (event) or r. 
In (65), modal transition systems are synthesized from 
properties in Fluent Linear Temporal Logic [26] and 
traces of scenarios. A modal transition system (MTS) (43l 
is a generalization of an LTS. An MTS has two transition 
relations, one describing possible transitions and the 
other required transitions. Possible transitions that are 
not required can be made required or proscribed in later 
phase of model development. Sibay et al. |60[ translate 
existential LSCs to MTSs. Krka et al. synthesize MTSs 
from a set of basic SDs and OCL constraints (42l - 
one MTS for each component of the specified system. 
Refinement of MTSs has been studied in El, (221, (23l. 

Defining semantics of SDs via translation allows us 
to leverage established results in other areas to analyze 
SDs. Bisimulation El, 123, E3L EH, must preorder 1551 , 
[36 1, [55] and failures preorder ff37l are close relatives (151 , 
(191 and have been used to define refinement of au- 
tomata and processes. Refinement in bisimulation, must 
and failures preorder semantics keeps required traces 
while decreasing non-determinism. However, the trans- 
lation algorithms are limited to small subsets of SDs and 
ignore essential features of SDs. For instance, they all 
ignore critical regions and they all except l40l ignore 
guard conditions. Note that guard conditions cannot be 
disregarded for conformance reasoning as pointed out 
in the previous section. It is difficult to extend these 
translation algorithms to include critical regions. 

2.4 Other Extensions to MSCs and SDs 

There have been work on empowering SDs and MSCs 
with more language constructs. We now briefly discuss 
those extensions that are more influential. Live Sequence 
Charts (LSCs) (161 , (33l are introduced to capture exis- 
tential and universal modalities. LSCs have been subject 
to as much study as MSCs and SDs (see references 
in (6j, (321 , 1331 ) and have had synergistic impact on 
SDs. Modal Sequence Diagrams (MSD) O, (33 are an 
extension of SDs to deal with challenges with negate and 
assert operators. In MSD, a modal stereotype is attached 
to an interaction fragment to specify whether it describes 
a hot (required) or cold (possible) behavior. 

Triggered MSCs (TMSCs) l59l are introduced to catch 
conditional scenarios. Each instance in a TMSC has a 
trigger and an action. A system satisfies a TMSC if when- 
ever it exhibits the behavior described by the trigger of 
an instance, its subsequent behavior is limited to the 
behavior described by the action of the instance. The 



meaning of a TMSC is an acceptance tree [35], [36] which 
maps a trace w to an acceptance set which is a measure 
of non-determinism of the system after exhibiting w. 
The must preorder has been adapted for Triggered MSCs 
(TMSCs) [59] . TMSCs do not have a construct similar to 
critical or use guard conditions 1591 . 

2.5 Summary 

In summary, a notion of semantics-based conformance 
is needed to allow more flexible reuse of SDs, which 
requires a formal semantics. There does not exist a 
suitable semantics for conformance reasoning because 
direct style semantics do not precisely capture required 
behaviors by SDs and translations to other formalisms 
disregard essential features of SDs. 

3 Abstract Syntax 

An SD specifies runtime behavior of a system in a 
graphical manner. It shows as parallel vertical lines 
different objects or processes that communicate with 
each other via messages that are shown as horizontal 
arrows. A simple diagram which does not have any 
combined fragment has been modelled as a partial order 
on event occurrences [8]. Intuitively, e\ ~> e2 indicates 
that ei occurs no later than e-i. Since ~> is asymmetric, 
there is unique irreflexive and non-transitive relation -» 
such that ~~»= -^>* where * is the reflexive and transitive 
closure operator. The relation -» is the transitive and 
reflexive reduction of and we call it a strict sequencing 
order. 

Events are basic behavioral constructs of UML SDs. 
They can be combined to form larger behavioral con- 
structs called fragments. A fragment is formed of an 
interaction operator, one or two operands which may 
be themselves fragments and an optional condition. It 
involves a collection of lifelines and is formed of events 
and smaller fragments. In this sense, an event is a 
primitive fragment. 

In this work, we do not consider interaction operators 
ignore, consider, assert, neg or break. Since we are con- 
cerned with checking if the behaviors described by one 
model are found in another model, ignore and consider 
fragments play no role and thus can be removed. Despite 
prior effort in clarifying assert and neg operators (3ll , 
1611 , no commonly accepted interpretation for these 
operators has been established. The UML 2.0 standard 
states that a break fragment is a breaking scenario that 
is performed instead of the remainder of its enclosing 
fragment. It is not clear whether the enclosing fragment 
means the innermost enclosing fragment or the inner- 
most loop fragment. We assume that all references to SDs 
through interaction operator ref have been eliminated via 
syntactic unfolding since SDs are non-recursive. 

Let Name be a denumerable set of names of messages, 
lifelines, system variables and values. An event e in 
Evt has the following structure. An event sending a 
message with name N € Name, sender S £ Name, 
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receiver R G Name, parameter list P C Name is written 
as (\,N(P),S,R) or \N(S,R,P), and the corresponding 
receiving event (?,N(P),S,R) or 7N(S,R,P). We shall 
simply write \N(P) or ?N(P) when the sender and 
receiver are clear from context. Application of a function 
p : Name H> Name to a syntactic object o, denoted p(p), 
is obtained from substituting p(n) for each occurrence of 
n in o. We abstract from details of guard conditions c in 
(Dnd and require that the collection of guard conditions 
are closed under classical logical negation (-> c ), con- 
junction (A c ) and disjunction (V c ) operations. We write 
ci \= c C2 iff c 2 is true in all value assignments in which 
ci is true. Other primitive syntactic entities are labels 
I in Lab and r representing unobservable events. The 
abstract syntax for SDs in Sid is given below. 

D ::= t | e | opi(c,Di) | alt(c,D 1 ,D 2 ) | loop{c,Dx) 
| critical(Di) \ par(Dx, D 2 ) \ strict(D\, D 2 ) 
| seq(Dx, D 2 ) \ block{L, l, -») 

where the interaction operator WocA: is introduced to 
structure operands of other interaction operators, L is 
a non-empty set of labels, l is a mapping from L to Sd, 
-» is an irreflexive and non-transitive relations on L such 
that is a partial order. The mapping l associates each 
label in L with an SD. (£,*,,-»*) is a partially ordered 
multiset 1571 . 

Example 3.1: The SD Login in Fig. [T]is represented 
in the abstract syntax as Login = block({1..6, a}, {i t-> 
e, | 1 < « < 6} U {a n> £>a},^o) where -^> = 
{(1,2), (1,3), (3, 4), (2, 4), (4, 5), (5, 6), (6, a)} and D a = 
opt(OK = true, block({7, 8}, {7 ^ e 7 , 8 h-> e 8 }, {(7, 8)})). 

Example 3.2: Consider the SD in Fig. [2] for email 
communication where fragments and events are labelled. 
In particular, the outer opt fragment is labelled 7. The 
sending and receiving events for a message in the SD are 
labelled with two consecutive numbers. Let a abbreviate 
the event labelled i as e,;. For instance, e\ abbreviates 
(\,request(sender, receiver), sender, op). Then the SD is 
expressed as Da pp = block({1..7},{i h-> | 1 < i < 
6} U {7 h-> f 7 }, ^ ) where -» = {(h i + 1) | 1 < i < 6} 
and ff = opt{authoried = true, block({8.. 12}, {i i— > | 
8 < i < 11} U {12 / 12 }, -kj)) with = {(», i + 1) | 
8 < i < 11}, /12 = block({13..l8},{i ^ e, \ 13 < i < 
18}, {(i, »+l) | 13 <»< 15} U {(15, 17), (17, 18)}). 

4 Semantics 

This section presents the semantic domain and the se- 
mantic equations for the trace semantics. We first in- 
troduce auxiliary notations and operations used in the 
construction of the domain and the definition of the 
semantic equations. 

Let S be an alphabet. E* denotes the set of all strings 
over S. The empty string is denoted e. A language L 
over S is a set of strings over E. The Kleene closure of 
L is denoted L*. Let u e E. The length of uj is denoted 
\u)\. The string u) may be thought of as a function from 
{0..|w| — 1} to E. The i-th element in ui is written as 



The interleave of two strings is the set of strings obtained 
by interleaving the two strings in all possible ways. Let 
x,y G E and p, v 6 E*. The following definition of the 
interleave operator || is due to [62[. 

e HI M = Mll|e = M 
xp III yv = {x} • (p HI yv) U {y} • (xp ||| v) 

where • is the language concatenation operator. 

Let © be a binary operation on domain S. Then ©" 
denotes this binary operation on p(S) defined as follows. 

X © B Y = {x © y | x G X A y G F} 

For instance, Cr, u" and are respectively pair wise set 
intersection, set union and language concatenation. 

M 1 n t M 2 = {C x nc 2 1 Ci G Mi AC 2 G M 2 } 
M 1 U t M 2 = {C x UC 2 | Ci G Mi AC 2 G M 2 } 
MiJM 2 = {Ci »C 2 I Ci G Mi AC 2 G X 2 } 

A rewriting relation =>■ on a set A is a binary relation 
on A. An element o e 4 is a normal form if there is no 
a' G A such that a =>■ a'. A rewriting relation =>■ is called 
finitely terminating iff it has no infinite descending chain 
ao ai =>• 02 • • It is called confluent if, for each 
x,u,w G A such that x =>* u and a; =>* u>, there is a 
z such that m =>* z and w ^* z. => is called convergent 
if it is both confluent and finitely terminating. If => is 
convergent, then for each a there is a unique normal 
form a', denoted a^,, such that a ==>* a' (4). 

Let dom(f) be the domain of a function / and 
image(f) = {f(x) \ x G dom(f)} the image of /. 

4.1 Semantic Domain 

An SD is a partial specification of required and prohib- 
ited behaviors of an application. This paper is concerned 
only with required behaviors. Consider this simple SD. 
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The SD has four events !m,?m, In and In 
and its strict sequencing order is -» = 
{(!m, ??ti), (In, In), (!m, In), (?m, In)}. An implemen- 
tation that produces the trace \mlm\nln satisfies this 
specification; another implementation that produces the 
trace \mln?m?n also satisfies the specification. Thus, 
the SD specifies two alternative minimum obligations 
Oi = {\mlm\nln\ and 2 = {\mlm\nln}. Of course, 
an implementation that non-deterministically produces 
one of the two traces also satisfies the specification. 
However, the obligation Oi U 2 is redundant since it 
includes Oi and 2 as proper subsets and hence not 
minimum. An obligation may contain more than one 
traces. Once an obligation is chosen, all traces in the 
obligation are required in that for each trace t in the 
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Fig. 2. An SD for an application that enforces Mandatory Access Control 



obligation, there is an interaction that produces t. For 
instance, alt(v = ok, !m, In) has one obligation with two 
traces {(v = ok)\m, (v ^ ok)\n}. A condition such as 
(v = ok) is a guard for the rest of the trace, meaning that 
the rest is exhibited only if the condition evaluates to 
true. The above obligation requires an implementation 
to produce !m if (v = ok) is true when it runs and to 
produce In if (v ^ ok) is true. 

A critical fragment requires that there is not any inter- 
vening event between two consecutive events in the re- 
gion. For instance, a critical fragment in the specification 
of a telephone service may specify that after receiving a 
911 call from the user, the operator must forward the 
call to the emergency service without any interruption. 
Another example is the specification for a home security 
system. It may specify that after receiving an abnormal 
response from the sensor, the alarm cell must set off the 
alarm device and alert the security agency and these 
messages must occur as an uninterrupted sequence. We 
wrap a sub-trace from a critical fragment and treat it as 
a single token. 

A trace is a sequence of tokens which are either events, 
guard conditions or critical segments (a) where er is 
a sequence of events and guard conditions. A critical 
segment \a\ protects the sub-trace a from interference. 
Occurring in a trace, \a\ will be treated as atomic when 
the trace is combined with other traces through inter- 
leaving and weak sequencing. The domains of tokens 
and traces are respectively 

Tk = EvtU(DndUfl(EvtUCnd)*D 
Tr = Tk* 

Consider two required traces elm and -i c (c)!to. Then 
message m is always sent since it is always the case that 
either c or -> c (c) holds. Occurring in an obligation, they 
represent an unnecessary decision point. Define — o by 
OU{ac/3, ac'/3} -o OU{a/3} if cV c c' |= c true. Then -o is a 
convergent rewriting relation on obligations. So, function 
fold(O) = 0_o is well defined. The function is lifted to 
sets of obligations as fold(M) = {fold(O) | O G M}. 
Define 

I M = {O e M | -BO 1 e M.(0' c £>)} 



The operation I removes redundancy from its argument. 
The semantic domain is 

Sein = {M e p(p(Tr)) \ M =1 M A fold(M) = M} 
4.2 Semantic function 

The semantics of an SD D is denoted [D]. It is defined 
as the least solution to a system of semantic equations. 

4.2. 1 Observable and unobservable events. 

We are now ready for defining semantic equations. Ob- 
servable and unobservable events have obvious seman- 
tics: 

N = {{e}} 
[r] - {{t}} 
where e is the empty trace. 

4.2.2 Strict fragments. 

The concatenation of an obligation 0\ in [D\] and an 
obligation C 2 in [D2] gives rise to an obligation O in 

[strict{D u D 2 )\. 

[strict(D 1 ,D 2 )] =1 /bW([Di] •» [D 2 ]) 

where fold is applied to eliminate unnecessary decision 
points and I to remove redundant obligations. These 
functions are also applied in semantic functions for other 
kinds of fragment. 

4.2.3 Critical fragments. 

The semantics of critical(D) is defined by unwrapping 
all critical segments in traces of D and wrapping the 
result in (|-[). Define rx by a(jcr[)/? rx aa/3. A rewriting 
step with rx exposes a sub-trace protected by a critical 
segment. Since rx is convergent, unwrap (a) = is 
a well defined function. Define wrap (a) = (jcr[) . The 
function unwrap is lifted to sets of sets as unwrap(M) = 
{{unwrap(uj) | u> £ O} \ O 6 A4}. Lift wrap in the same 
way. The semantics of critical(D) is defined 

[critical(D)] = wrap (4. fold (unwrap ([D]))) 

For instance, [critical(strict(e, /))] = {{(]e/D}} where 
e, / G Evt. 
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4.2.4 Alt fragments. 

The semantics of alt(c, D\, D 2 ) is obtained by pre- 
pending c to traces of D\ and -^(c) to those of D2: 

[alt(c,D 1 ,D 2 )] =ifold({{c}} .» [Di] U« {{- c (c)}} .« [D 2 ]) 

Let e,f,g e Evt and c e (Dnd. 
Then [aZi(c, e, e)] = {{ e }} aR d 

[aZi(c, strict(e, /),<?)] = {{ce/, c'g}} where c' = -'c(c). 

4.2.5 Opf fragments. 

The semantics of opt(c, D) is obtained similarly: 

M(c,D)] =lfold({{c}} .» [£>] U» {{- c (c)}}) 
For instance, [opi(c, r)] = {{e}}. 

4.2.6 Par fragments. 

Consider parallel interleave par(Di,D2) of two sub- 
diagrams. Let 0\ be an obligation of D\ and 02 of 
D 2 . Parallel interleaving produces a set of alternative 
obligations from 0\ and 2 . Define 

01 1||02 = {O I Vcri G 0i.cr 2 £ V0 2 .3a G 0.(cr G o"i ||| <7 2 )} 

0i HI 02 may have redundant obligations. Put 

0i = {ei} and 2 = {e 2 }. Then 0i|||0 2 = 
{{eie 2 },{e 2 ei},{eie2,e2ei}}. The obligation {eie 2 ,e 2 ei} 
is redundant. The meaning of par(D\, D2) is defined 



[par(D 1 ,D 2 )] = [D 1 ] \\\ b [D 2 ] 



where 
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Example 4.1: Let c G (Dnd and f,g, h G Evti. Then 

bar(aZt(c,/, 5 ),/i)] = {{c/,c' 5 }} ||| b {{^j} 
{/ic/, hc'g}, {hcf, c'hg}, {hcf, c'gh}, 
{chf, hc'g}, {chf, c'hg}, {chf, c'gh}, 
{cfh, hc'g}, {cfh, c'hg}, {cfh, c'gh} 

where d = -i c (c). 

4.2. 7 Block fragments. 

To enforce sequencing orders, we tag tokens in a trace 
generated from a fragment. Function tag labels each 
token in a trace by a given label: tag(e,£) = e and 
tag(t ■ a, I) = (t,£) ■ tag(cr,£). Function untag does the 
opposite and is defined untag(e) = e and untag((t,£) ■ 
a) = t ■ untagid). tag and untag are extended to sets of 
sets in the same way as unwrap. Function lifelines maps a 
token to the set of the lifelines associated with the token. 
A sending event is associated with the sender, a receiving 
event with the receiver and a critical segment with all 
the lifelines associated with the events in the critical seg- 
ment, lifelines is defined by lifelines ((\ , N(P), S, R)) = 
{5}, lifelines ((?, N(P),S,R)) = {R}, lifelines (H) = 
Uiedom(cr) lifelines (a (i)) and lifelines (c) = 0. Let lb be the 



function that returns the label of a tagged token. Then 
lb((t,£)) = £. Relation ~ relates two tagged tokens iff 
they share lifelines: (ti,£i) ~ ^,£2) iff lifelines (ti) D 
lifelines (t 2 ) ^ 0- Let Tt = (Tk x Lab)* be the set 
of tagged traces. The set of traces of tagged tokens 
satisfying a strict sequencing order is denoted st(-»). 



St{ ~* ] -{ aeTt \ \lb(a(^) l Z*lb(a(j)) ^(i< j)) 
The semantics of block fragments is defined as 



[block{L,L,^)\ = untag({st{^)}CP (\\\\ eL tag([i(£)],l))) 

Traces from immediate sub-fragments of block (L, 1, -») 
are first interleaved in all possible ways and then those 
traces are removed that violate the strict sequencing 
order -». The labels that are used to tag tokens do not 
occur in the resulting semantics; they are only used in 
enforcing the strict sequencing order -». 

Example 4.2: Continue with Example 13.11 We have 
[D a ] =1 fold({{[OK = true]}} •* [block{{7,8},{7 ^ 
e 7) 8 ^ e 8 },{<7,8)})] U» {{[OK = false]}}) = 
{{[OA' = true] e-je%, [OK — false]}} and {Login] = 
{{ r i> r 2},{r' 1 ,r' 2 }} where ri,r 2 ,r' 1 and r' 2 are given in 
Example 11.21 

4.2.8 Seq fragments. 

The interaction operator seq combines traces from com- 
ponent SDs via weak sequencing. The semantics of 
seq(Di, D 2 ) is obtained as follows. Every token in each 
trace in [DJ is tagged with 1 and every token in each 
trace of [Do] is tagged with 2. Tagged traces are then 
interleaved as in the semantics of par[D\,D2). Then 
any tagged trace that violates weak sequencing order 
imposed by seq is removed. The set of tagged traces that 
satisfy the weak sequencing order is 



VO < i,j < \a\. 
( (lb(a(i)) = 1 \ 

A 

lb(a(j)) =2 => (i < j)) 

A 

V (&[i] ~ a[j]) ) 



Tt seg = < 



a G Tt 



The semantics of weak sequencing fragments is defined 



[se q (D 1 ,D 2 )] = [D 1 ]fA b [D2] 



where 



M A\ b Af = untag({Tt seq } n" (tag(M, 1) ||| b tag(N, 2))) 

Example 4.3: Let oi,o 2 be lifelines, f\ = 

(\,m,o 1 ,o 2 ), f 2 = (?,m,o 1 ,o 2 ), h = 0,", 01,02) 
and fn = (?,n, 01,02). Put D\ = strict(fi, / 2 ) and 
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D 2 = strict(fs, U). Then 
Pi] = {{/1/2}} 

p 2 ] = {{/ 3 /4}} 

[strict(D 1 ,D 2 )] = {{f 1 f 2 f 3 f 4 }} 

[seq(D u D 2 )] = {{/1/2/3/4}, {/1/3/2/4}} 
\par(D u D 2 )] = {{/1/2/3/4}, {/1/3/2/4}, {/1/3/4/2}, 

{/3/4/1/2}, {/3/1/4/2}, {/3/1/2/4/4}} 

Let t(i) = A for i = 1,2. The [Mocfc({l, 2}, t, {(1, 2)})] = 
[«*rict(Di,U 2 )], and |Wocfc({l,2},t,0)] = |por(Di, Z> 2 )]. 

4.2.9 /Loop fragments. 

The UML standard stipulates that traces from consec- 
utive runs of the loop body are combined via weak 
sequencing: [loop(c, D)] is the limit of this series: Xq = 
{K(c)}} and X i+1 = ({{c}} J ([D] A\ b X t )) U» {K(c)}}. 
An alternative definition would be 

[loop(c, D)] = ({{c}} J [seq(D, loop(c, £>))]) U« {{- c (c)}} 



4.2. 7 Properties of semantics. 

The abstract syntax requires that the block fragment has 
at least one immediate sub-fragment. As a consequence, 
a sequence diagram specifies at least one obligation. 

Lemma 4.1: Let D e $<d. Then 30 e [D].(0 ^ 0). 

Let Ewt(-D) be the set of observable events occurring 
in D. 

Lemma 4.2: If Evt(D) = then [D] = {{e}} = [r]. 

We adapt the concept of a context from term writing. A 
context is an SD with one of its fragments replaced by a 
special symbol x. For instance, seg(x, e) with e e Evt 
is a context. Let D be an SD and C a context. The 
embedding of D into C, denoted C[D] is the SD obtained 
from replacing x with D. Two SDs are called equivalent 
if they have the same meaning. The following propo- 
sition shows that the semantics possesses substitutivity. 
Substitutivity is a desirable property since it allows any 
fragment in an SD to be replaced with a semantically 
equivalent fragment. 

Proposition 4.1: Let C be a context and D 1 ,D 2 6 $d. If 
[DJ = [D 2 ] then [C[£>i]] = [C[£> 2 ]]. 

5 Semantics based Conformance 

In this section, we make precise of the notion of con- 
formance. There are a number of issues to consider in 
reasoning about SD conformance. One issue is renam- 
ing of lifelines, messages and system variables. When 
reusing an SD, the designer embeds it into a context. In 
doing so, the designer may need to change the names 
of lifelines and messages either for better conveying his 
intention or for avoiding name conflicts. Another issue 
is the introduction of new lifelines, messages and system 
variables which are unobservable in the original SD. The 
values that the unobservable system variables take affect 



the behavior of the specified system. Yet another issue 
is the use of guard conditions in fragment combination 
operators. The conformance relation we shall define is 
parameterized by a mapping that renames lifelines and 
assigning values to system variables p : Narnce 1— > Namce 
and a set of events U C Evt. The mapping p is 
called a substitution and it maps new names of lifelines, 
messages and system variables to their old names and 
assigns values to newly introduced system variables. 
Application of a substitution p to a syntactic object o, 
denoted p(o), is obtained from substituting p(n) for each 
occurrence of each name n in o. The latter induces 
a hiding function hideu on Sd. hideu(D) is the SD 
obtained from D by replacing all occurrences of e with 
t for each e 6 U. 

5.1 Trace Simulation Relation 

We first define a simulation relation between traces that 
take into account the use of guard conditions. 

Definition 5.1: Let c\,c 2 G Cnd, e±,e 2 6 Evt and 
a, 0, 7 e Tr. The trace simulation relation k is defined 
inductively as follows. 

« cjKc 2 if c 2 he c i- 

• e± x e 2 if c\ = e 2 . 

• d«D x (I7D if a x 7, 

• a x 7 if there are a trace f3 such that a rx* j3 and 
a strictly increasing function 77 : dom(/3) h-> dom^) 
such that 

(1) for any i e dom((3), f3(i) x 7(77(2')); and 

(2) for j e dom(j), if j $ image{r\) then 7(7) S Cnd. 
Some explanations are in order. A critical segment can 

only be simulated by a critical segment. The condition 
a rv* (3 allows events in protected sub-traces to be used 
to simulate events in 7 by breaking up zero or more 
occurrences of (j |). Note that (3 may be a itself. The strict 
monotonicity of 77 ensures that different events in 7 are 
simulated by different events in j3. The condition (2) 
ensures that if the events in 7 occur then the events in f3 
occur too. The condition (1) guarantees that each event 
in 7 is simulated by an event in /3. 

Lemma 5.1: If ct\ x a 2 and a 2 rx j3 2 then there is a /?i 
such that ai rx Pi and pi x p 2 . 

The following is the consequence of the reflexivity and 
transitivity of |= c . 

Lemma 5.2: x is reflexive and transitive. 

Example 5.1: Let ei,e 2 ,e 3 be different events and 
c a guard condition. Then e\ ■ e 3 x ei ■ and (jei ■ x 
(|ei • c • e 2 |). But, flei • e 2 • e 3 |) x (|ei • e 3 [) does not hold since 
e 2 is an event and it is between e\ and e 3 . Nor does c • 
ei x ei hold since there is no guarantee that the constraint 
c is satisfied. 

5.2 Refinement Relation 

We now introduce a special case of conformance called 
refinement. An SD specifies a number of alternative 
obligations and an implementation may choose to realize 
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any of them. An SD D\ refines another SD D 2 if any 
implementation of D\ is also an implementation of D 2 . 
Formally, 

Definition 5.2: Let D\,D 2 € Sd. D\ is said to refine 
D a , denoted D x >r D 2 , if Vd e [DJ.30 2 e [D 2 ].Vt 2 e 
2 .3ti 6 0i. (ii k i a ). 

The following lemmas follow from definitions of 
hideu, [•] and k. They state that both hiding and sub- 
stitution preserve refinement relation between SDs. 

Lemma 5.3: Let Di and D 2 be SDs. If Di >; D 2 then 
hideu (Di) h hideu{D 2 ) for any W C Evt. 

Lemma 5.4: Let D 1 and D 2 be SDs. If D x > D 2 then 
p(Di) >; p for any substitution p : Nairn ee H> Name. 

5.3 Conformance Relation 

We are now ready to define the conformance relation be- 
tween SDs. If we change D 2 to D-y, we need to make sure 
that p(hideu(Di)) refines D 2 where U is the set of newly 
introduced events, p is a substitution that reverses name 
changing and assigns values to new system variables. It 
is also necessary to make sure that events in U are not 
those that are used to simulate events in Evt(p(D2)). 

Definition 5.3: Let Di,D 2 <E Sd, p : Name i-> Name 
and U C Evt(Di). We say that D\ conforms to D 2 with 
respect to p and U, denoted Di> p ^D 2 iff 

1) p{U) n Evt(D 2 ) = 0, and 

2) p{hideu{D\)) >z D 2/ i.e., p{hideu{D{)) refines D 2 . 

We say that D\ conforms to D 2 , denoted D\[>D 2 iff 
Di> Pj wD 2 for some p : Name >-> Name and some U C 
Evt(Di). 

Note that refinement is a special case of conformance 
in which U = and p is the identity function. In other 
words, D\ conforms to D 2 whenever D\ refines D 2 . 

Example 5.2: Continue with Example 14.31 Let 
p be the identity function and U = 0. It can 
be verified that strict(D\, D 2 )\>seq{D\, D 2 ) and 
seq(D 1 ,D 2 )>par(p u D 2 ). 

Therem 5.1: The conformance relation > is reflexive 
and transitive, i.e., 

1) D > D for any D g Sd; 

2) if Di > D 2 and D 2 > D3 then D\ > D 3 for any 

D!,D 2 ,D 3 G Sd. 

Example 5.3: This example shows that SD Login2 
conforms to SD Login. Let denote the event that is 
labelled i. Then Login2 = block({b, 5, 6, 11, 12, c}, 
{b ^ D 6 ,5 M. / 5 ,6 ^ / 6) 11 ^ / Uj 12 ^ 
/ 12 ,c 1 ^ D c }, {(b, 5), (5, 6), (6, 11), (11,12), (12, c)}) with 
D b = strict(block({l,2},{l ^ A, 2 ^ / 2 }, {(1, 2)}), 
strict(block( {3,4}, {3 h-> / 3 ,4 H. / 4 }, {(3, 4)}), 
W«*({9, 10}, {9 1 ^ / fll 10 ^ fw}, {(9, 10)}))) and D c = 
opt(pOK = trueAkOK = true, block({7, 8}, {7 H- / 7 , 8 ^ 
/ 8 }, {(7, 8)})). Let W - {/ 9 , ho, fnjw} and 

{customer 1— > user, brokerage 1— > server, ^ 
acc 1— > id, pin 1— > pwd, chkP 1— > c/i/c, > 
pOK 1— >• Oif , trade 1— > cmii, fcOJi' n> true J 



Then p(/j) = for 1 < i < 8 and 

p{hideu(D b )) = 

strict{block{{\, 2}, {1 h-> e x , 2 i-> e 2 }, {(1, 2)}), 
strict(block({3, 4}, {3 H> e 3 , 4 (->■ e 4 }, {(3, 4)}), 
Mocfc({9, 10}, {9 1 — )■ t, 10 1 — )■ t}, {(9, 10)}))) 

By the definition of [■], 

[Wocfc({9, 10}, {9 ^ r, 10 ^ r}, {(9, 10)})] = {{e}} 
[Wocfc({l, 2}, {1 ^ ei, 2 ^ e 2 }, {(1, 2)})] = {{ ei e 2 }} 
[Wocfc({3, 4}, {3 h-> e 3 , 4 h- e 4 }, {(3, 4)})] = {{e 3 e 4 }} 

\p{hide u {D b ))\ = {{eie 2 e 3 e 4 }} 

and p{hide u {D c )) = opt(OK = true, block ({7, 8}, {7 (->■ 
er,8 h-> eg}, {(7, 8)})) after the tautology trite = irwe is 
removed from the guard condition. Thus, 

\p(hide u (D c ))] = {{[OK = true]e 7 e 8 , [OK = false]}} 

Finally, let Login' = p(hideu{Login2)), D' b = 
p{hideu{Db)) and D' c = p(hideu{D c )). Then Login' = 
block({b, 5, 6, 11, 12, c},{b ^ D' b ,5 ^ e 5 ,6 h-> e 6 ,ll <-> 
r, 12 m. r, c ^ £)J.}, {(6, 5), (5, 6), (6, 11), (11, 12), (12, c»). 
Since the strict sequencing order in SD Login' is total, 
traces from its components are combined using string 
concatenation and 

[Login') = {{ ^e 3 e,e 5 e e [OK = true]e 7 e 8 , lj 
1 J |_ [ eie 2 e 3 e 4 e 5 e 6 [OA = false] J J 

= {{n,r 2 }} 

where r 4 and r 2 are given in Example 11.21 Recall from 
Example 14.21 [Login] = {{ri, r 2 }, {r[, r' 2 }} where r[ and 
r' 2 are also given in Example 11.21 

Put D\ = Login2 and D 2 = Login. Then it can be 
easily checked that the condition 2 in Definition 15.31 
holds. The condition 1 in Definition 15.31 holds because 
p(h) = fi and fi £ Evt(Logiri) for 9 < i < 12. Thus, SD 
Login2 conforms to SD Login with respect to p and U. 

6 Case example: Mandatory Access 
Control 

This section illustrates via an example how the confor- 
mance of an SD to an access control pattern can be ver- 
ified. Access control is an important aspect in trustwor- 
thiness computing to ensure integrity, confidentiality and 
availability of shared resources in a system. Thus, their 
behaviors must be strictly observed, otherwise security 
breaches or denial of services to authorized users may 
occur. We use Mandatory Access Control (MAC) Il58l 
which governs access based on security levels. 

Figure |3] shows the interaction behavior of MAC. The 
SD describes that subject Sb requests operation Op to 
be performed on object Ob. The request is checked for 
accessibility by the ChkAccess operation on reference 
monitor RM which enforces the Simple Security property 
and the restricted-* property f58| for controlling read and 
write accesses. The opt fragment specifies that if the ac- 
cess is authorized, the request is sent to the target object 
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through two object liaisons OL1 and OL2 which delegate 
the request. The SD is represented in the abstract syntax 
D Inst = block({1..7},L,{[(i,i+l) | 1 < i < 6}) where 

4(1) = (\,RequestOp(Sb,Ob),Sb,Op) 

4(2) = {?,RequestOp(Sb,Ob),Sb,Op) 

4(3) = (\,ChkAccess(Sb,Ob,Op),Op,RM) 

4(4) = (?,ChkAccess(Sb,Ob,Op),Op,RM) 

4(5) = (!, Authorized, RM, Op) 

4(6) = (?, Authorized, RM, Op) 

4(7) = opt(Authorized = true, 

block({8.A3}, 41, {(i, i + I 8<i< 12}) 

4i (8) = (\,InitOp(Op),Op,OLl) 

tl (9) = (7,InitOp(Op),Op,OLl) 

4i (10) = (\,DelegateOp(Op),OLl,OL2) 

ii (11) = (?,DelegateOp(Op),OLl,OL2) 

ii (12) = (\,PerformOp(Op),OL2,Obj) 

tl (13) = (?,PerformOp(Op),OL2,Obj) 



We have developed a prototype tool for conformance 
inference in Prolog. Given two SDs Z?i and D2, the tool 
finds every pair (tW,p) such that D\X> P uD2- The tool 
infers that -D^pp in Example 13.21 conforms to Dj nst with 
respect to p and W given below. Since Di nst is an instance 
of the MAC pattern, we conclude that -D^p conforms to 
the MAC pattern. 



drawing a layer into the view. When there is a request 
for adding a background as an instance of a painter 
implementation, the requested background is stored in 
a vector and the current view is repainted for each 
background in the vector. We have labelled events and 
combined fragments. For instance, the opt fragment is 
labelled 14. The sending and receiving events for a 
message in the SD are labelled with two consecutive 
numbers. Let ej abbreviate the event labelled i. For 
instance, e-2 abbreviates (!, create (), d, v). Then the SD is 
expressed as Djhd = block({l.A7},{i H> | 1 < i < 
17 A i ± 14 A i 56 17} U {14 m. / u ,17 h+ /i 7 },^ ) 
where ^> = {(i,i + l) | 1 < i < 16}. The sub-SD 
/14 = opt(v\ = nullAlisPrinting, block({18, 19}, {i \-t 
I 18 < i < 19}, {(18, 19)})) and the sub-SD / 17 = 



loop((l < i) A (i < dim),block({2Q..25},{j 



20 < 



U = 



(!, sort(receiver) , sorter, sorter), 
(?, sort(receiver) , sorter, sorter), 
(!, log(receiver), deliver, transaction) , 
(?, log(receiver), deliver, transaction) 



j<25},{(e j ,e j+1 ) 20 < j < 25})). 

The SD for the Observer pattern is shown in Fig. [5] 
Abbreviate the event labelled with j as e^. Then the SD 
is represented as D oos = block({l, 2, 3}, {1 i-> 6^,2 1-^ 
4,3 ^ / 3 }, {(1,2), (2, 3)}) where / 3 = loop(l < k/\ 
k < NumO j Observers, block({4. .7 ', {i e[ \ 4 < i < 
7}},{(M+l)|4<i<7})). 

The prototype tool found the following three pairs of 
values for (p,U) with respect to which Djhd conforms 
to D b s where non-null indicates any value which is not 
null. 

Hi = {ei I i G {1..5, 8.. 13, 15, 16, 18. .21}} 

!d H» sub, s M> obs, repaint 1— > notify, 
draw 1 — ^ update, draw All 1— > getState, 
i i—> fc, dim 1— > NumO f Observers 
U 2 = {ei I i G {1..11, 15, 16, 18.. 21}} 

c? H> sm6, s 1— )• 06s, drawBackground 1— > notify, 



request <-> RequestOp, check <— > Chk Access, 
perform 1— > InitOp, send2 1— » DelegateOp, 
send3 1— ^ PerformOp, 
authorized 1— > Authorized, 

found 1 — ^ true, sender 1-} Sb, op M- Op, receiver t— > 
si i-> i?M, sorter \-> OL1, deliver OL2 



P2 



Oft, 

P3 



7 Case Example: JHotDraw 

We have also conducted a case study using JHotDraw 
5.2, an open source framework for building graphical 
drawing editors. JHotDraw is known to be pattern-based 
where sixty instances of ten different design patterns are 
found |64| . We specifically looked into the three instances 
of the Observer pattern. We reverse-engineered the in- 
stances using NetBeans 5.5 to generate corresponding 
UML sequence diagrams and combined them to make 
the pattern behavior more explicit. We checked con- 
formance relationship between the combined sequence 
diagram and the Observer IPS presented in our previous 
work 1391 . 

The SD in Fig. [4] describes the part of JHotDraw be- 
havior that pertains to adding backgrounds to a drawing 
view through painters which defines the interface for 



draw 1— > update, drawAll 1— > getState, 
i 1 — y k, dim 1 y NumO f Observers 
{e,\ie {L.13,15,16,20,21}} 

d H> sub, s 1 — y obs, drawPainters <— > notify, 
draw t— > update, draw All i-> getState, i 1— > k, 
dim 1 — y NumO f Observers, 
isPrinting 1— > false, v <-> non-null 



These three pairs of values correspond to three ways 
in which Djhd conforms to D b s and they differ in how 
notify message is realized. Without semantic information 
about operations in SDs, the tool cannot tell which of 
the three ways is intended by the designer. Neverthe- 
less, information the tool provides is valuable in that it 
presents all possible ways the Observer pattern D b s is 
realized in Djhd- Note that values of v and isPrinting in 
P3 satisfy the condition of the opt fragment in Djhd- We 
have also studied another variant of the Observer pattern 
in which the update message carries the object sub as an 
argument. The tool infers that Djhd does not conform 
to the variant. This is correct since the draw message 
in Djhd does not carry the subject d as an argument 
and d is the lifeline in Djhd which corresponds to sub in 
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the variant of the Observer pattern. The variant of the 
Observer pattern is an example of over-specification. 

8 Conclusion and Future Work 

Reasoning about conformance between SDs with respect 
to their required behavior is an important issue in soft- 
ware development process such as aspect-oriented and 
pattern-based software development. In this paper, we 
have presented a trace semantics for SDs that captures 
precisely required behavior of SDs and formalized a 
notion of conformance based on the semantics. By way 
of two case examples, we showed how pattern confor- 
mance can be verified. 

One future work will be integrating class diagram con- 
formance presented in ||46ll and SD conformance relation 
presented in this paper. Another future work is to extend 
the semantics and the conformance relation to include 
interaction operators neg and assert. This requires to take 
into account the proscribed behaviors of SDs. We also 
plan to use the semantics proposed in this paper as a 
basis to investigate the correctness of the algorithms that 
translate SDs to other design models such as statecharts 
and modal transitions systems. 
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Appendix 

PROOF OF LEMMA H7Q By structural induction on D. 
The base cases where D = r and D = e are trivial. 
Assume that D = opt(c,Di), by induction hypothesis, 
3d € [DJ.(Oi 0). Let O = {ct | t G O x } U {- c (c)}. We 
have that 0^0 and O £ [fl], Other inductive cases are 
similar. I 

PROOF OF LEMMA |42] Proof can be done by structural 
induction on D in a similar way to Lemma 14.11 except 
that there is only one base case since Evt(e) ^ 0. I 

PROOF OF PROPOSITION ED The proof is done by 
structural induction on C. In the base case, C = x. We 
have [C[L>i]] = pi] = [D 2 ] = [C[D 2 ]j. 

Now assume that C = opt(c,C). By the induction 
hypothesis, we have [C"[£>i]] = [C'[D 2 ]]. Then 

[C[£>i]] = [opi(c,C'[Di])] 

= i/oM({{c}}.»[C'[A]]U»{K(c)}}) 

= ifold({{c}}.nC'[D 2 }]uH{-M}}) 
= [opt(c, C'[D 2 })] 

= \C[D 2 ]] 
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Other inductive cases are similar. I 

PROOF OF lemma [5TTJ Without loss of generality, we 
assume that a.\ is a sequence of tokens, for otherwise 
the result follows immediately. Then by definition of x , 
there are an a 1 such that ct\ rx* a' and an 77 : dom(a') i-> 
dom(a 2 ) such that 

(a) For any i £ dom(a'), a'(i) X 0^(77(7)); and 

(b) For any j £ dom(a 2 ), if j ^ image{r\) then a 2 (j) £ 
Cnd. 

Since a 2 rx /3 2 , there are wi,w 2 arid ui 3 such that a 2 = 
widaj 2 Dw3 and /3 2 = wiw 2 w 3 . Since 77 is strictly increasing 
and a 2 (||wi||) = (|w 2 D (Dnd, there is a unique £ such that 
77^) = ||wi||. There are also u\, u 2 and u 3 such that \\ui\\ = 
£, a' = u\(\u2\)U3 and 7i 2 xcj2- Let a" = u\U2U 3 . Then a rx* 
a' rx a". Since U2 and cj2 do not contain critical segment 
tokens and 112 x U2, there is an 77' : dom(u2) *-> dom(uj2) 
such that 

(c) For any i 1 £ dom{u2), U2{i') x u>2{rj' {i')); and 

(d) For any j 1 £ dom{u>2), if j' ^ image{rf) then LO2W) £ 
(Dnd. 

Since «i rx* uil\u2\)u 3 , there are «i and tj 2 such that 
ai = v 1 <\u 2 \jv 3 and «i rv* u x and u 3 rv* u 3 . Let 
Pi = viu 2 v 3 . Then a.\ rx fii rx* uiu 2 u 3 — a". Now define 
rj" : dom(a") h-> dom((3 2 ) as follows. 

»/'(*") = < rf{i"-£) t<i" <t+\\Lo 2 \\ 

[ »,(*"- |M| + 1) »">*+|MI 

The following follows from (a)-(d). 

. For any i" £ dom(a"), a"(i") x /3 2 (v"(i")); and 
• For any j" £ dom(/3 2 ), if j" $ image(ri") then 
/3 2 (i") £ Cnd. 
So, fa x I 

PROOF OF LEMMA |52] Let 7 be an arbitrary trace. 
We prove 7 k 7 by structural induction on 7. In the 
base case where 7 = e, e x e by definition. In the base 
case where 7 = c, c x c follows from reflexivity of (= c . 
In the case where 7 = (fy'D, we have 7' x 7' by the 
induction hypothesis, which implies 7x7. Assume that 
7 = t\ ■ ■ • t n . By the induction hypothesis, we have that 
ti x ij for < i < n. Then 7 x 7 by putting a = f3 = 7 
and 77(7) = z for any < i < n in the definition of x. 

Assume that a x (3 and /3 x 7. We prove a x 7 by 
structural induction on a. Case (a): a = e. Then /3 must 
be of the form wiew 2 with cji,oj 2 £ (Dnd*. Since (3 x 
7, there is a strictly increasing function 77' : dom(/3) \-> 
dom^) such that 

(1') For any i £ dom(j3), f3(i) x 7(77' (i)); 
(2') For any j £ dom{"f), if j image (77') then 7(7) £ 
Cnd; 

Let £ be the unique position at which e occurs in f3. Then 
(2') implies that 7(7) £ (Dmd for all j 7^ 7/(£); (1') implies 
that 7(V(<0) = e. Thus, a x 7. 

Case (b): a = c for some c £ (Dnd. Similar to Case (a). 



Case (c): a = i\a"i). There are (3' and 7' such that 

P = 7 = (P/D/ «' K and P K 7'- B Y the induction 
hypothesis, we have a' x 7' which implies 0x7. 

Case (d): Since j3 x 7, there are /3' such that /3 rv* /3' 
and 772 : dom(f3') i-> domiry) such that 

(i) For any z £ dom(j3'), (3'{i) x 7(772(2)); 

(ii) For any j £ dom(j), if j ^ image^) then 7(j) £ 
(Dnd; 

Since a x /3, there is an c/ such that a rv* a' and a' x /3' 
by Lemma [5. II Thus, there are an a" such that a' rx* a" 
and an 771 : domia") i-> dom((3') such that 

(iii) For any i £ dom{a"), a"(i) x f3'(r]i(i)); 

(iv) For any j £ dom(J3'), if j ^ image(r}i) then /3'(j) £ 
Cnd; 

Now define 77 : dom(a") i-> dom(^) by 77 = 7/2 o 77!. Then 
(i)-(iv) imply that 

• For any i £ dom(a"), a"(i) x 7(77(7)); 

• For any j £ dom(j), if j image (rj) then 7(7) £ 
(Dnd; 

This, together with a rx* a", implies that a x 7. I 

PROOF OF LEMMA E3] Let hide u {t) be the result of 
replacing each occurrence of e in t with e for each e £lA. 
hideu is extended to obligations and meanings as tag 
is. Then [hideu(Di)] = hideu([Di]) for i = 1,2. By a 
simple structural induction on t\, we have t\ x r;2 implies 
hideu{t\) x hideufo)- The result follows. I 

Proof of lemma [53 Observe [p(A)] = p([A]) for 
i = 1, 2. Since p is a function on Name, we have ii x t 2 
implies p(t±) x pfa)- So, the result follows. I 

Proof of theorem |5J] (p. [10): 

1) To prove £>[>£». Let D A = D 2 = D. Put W = and 
p(x) = x for all x £ Name. Then condition (1) in 
Definition 15.31 holds since U = 0. Consider condi- 
tion (2) in Definition E3 We have L>i = D' 2 = D. 
Then condition (2) in Definition 15.31 holds because 
of reflexivity of x . 

2) Now assume Di\>D 2 and D 2 >D 3 . Then there are 
renaming substitutions p\ , P2 and sets of events 
U x C Evt(L»i),W 2 C Evt(D 2 ) such that 

(a) /j 2 (W2)nEvt(L> 3 ) = 0, 

(b) V0 2 £ pg.30 3 £ [D 3 ].yt 3 £ 3 3t 2 £ 2 .{t 2 x 
t 3 ) where D' 2 = p2(hideu 2 {D 2 )) ■ 

(c) px(Ui) n Evt(£> 2 ) = 0, and 

(d) VOi £ [£>i].3C7 2 £ [£> 2 ].Vi 2 £ 2 3h £ O^h x 
t 2 ) where D' x = pi(hide Ul (Di)). 

Let /? = p 2 Pi/ and U =U\\JlA' 1 where W{ = {e \ 
e £ Evt(D x ) A pi(e) £ W 2 }. Then W C Evt(£>i). 
Let e 3 be an arbitrary event in Evt(D 3 ) and ei be 
an arbitrary event in Evt(Dx) such that e\ = p(es). 
We now prove that e\ $ U by way of contradiction. 
Assume that &\ £ U. Then there is no event e 2 £ 
Wjvt(D 2 ) such that pi{e\) = e 2 according to (c). 
Thus, the condition (1) in Definition 15.31 holds. 
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Now consider the condition (2) in Definition 15.31 
Note that pi(U[) =U 2 . 

D'l = pohide u {D x ) 

= p2 ° Pi ° hide UlUU ^ (Di) 

= P2 Pi° hide U { o hide Ul (Di) 

= p2° hideu 2 o pi o hideiii (-Di) 

= p2 o hideu 2 (D[). 

The condition 2 in Definition 15.31 then follows from 
Remarks 15.31 and 15.41 and transitivity of X . 



